[% setvar title Objects should have builtin stringifying STRING method %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='TITLE'></a><h1>TITLE</h1>
<p>Objects should have builtin stringifying STRING method</p>
<a name='VERSION'></a><h1>VERSION</h1>
<pre>  Maintainer: Nathan Wiger &lt;<a href='mailto:nate@wiger.org'>nate@wiger.org</a>&gt;
  Date: 6 Aug 2000
  Last Modified: 14 Sep 2000
  Mailing List: <a href='mailto:perl6-language-objects@perl.org'>perl6-language-objects@perl.org</a>
  Number: 49
  Version: 3
  Status: Frozen</pre>
<a name='ABSTRACT'></a><h1>ABSTRACT</h1>
<p>Currently, $ single-whatzitz types in Perl can hold several different
things. One of the things that these are commonly used to hold are
objects, such as:</p>
<pre>   $q = new CGI;
   $r = Apache-&gt;request;</pre>
<p>Unfortunately, there is no easy way to tell these are actually objects
without lots of annoying ref checks throughout your code. So if you say:</p>
<pre>   print &quot;$q&quot;;</pre>
<p>This prints out something like this:</p>
<pre>   CGI=HASH(0x80ba4e8)</pre>
<p>Which isn't very useful. This RFC attempts to fix this by providing
builtin special method <code>STRING</code> which is automatically called when an
object is &quot;stringified&quot;.</p>
<p>While this can be accomplished through the use of 'use overload', a more
automatic, object-specific method has certain advantages. For more
details on this, please see RFC 159.</p>
<a name='NOTES ON FREEZE'></a><h1>NOTES ON FREEZE</h1>
<p>This RFC goes into details on the uses of <code>STRING</code>, but what you really
want to read is <i><a href='#RFC 159: True Polymorphic Objects'>&quot;RFC 159: True Polymorphic Objects&quot;</a></i>, which extends
these concepts to other Perl operators and contexts.</p>
<a name='DESCRIPTION'></a><h1>DESCRIPTION</h1>
<p>Currently, there is no way to easily distinguish between these two
syntaxes:</p>
<pre>   $scalar  =  date;     # scalar ctime date, same as localtime()
   $object  =  date;     # date object with accessor functions</pre>
<p>As such, there is no easy way to have the <code>date()</code> function return both
- it must decide what to return within the general scalar context.
Damian's excellent RFC 21 on <code>want()</code> addresses several specific cases,
several have suggested alternate syntaxes, such as:</p>
<pre>   my Date $object = date;   # return object of class 'Date'
   my tm $object = date;     # return object of struct 'tm'</pre>
<p>However, this doesn't solve the problem, since printing out either of
these in a scalar context still results in &quot;garbage&quot;.</p>
<p>I suggest that objects provide a default method called <code>STRING</code> that
determines what they produce in a string context. When stringified, an
object would automatically call its <code>STRING</code> function and return the
correct value. For example, RFC 48 describes a new <code>date()</code> interface.
In a scalar context, it could produce a date object always:</p>
<pre>   $date = date;</pre>
<p>However, when you went to do anything with it in a string context, it
would call the appropriate method:</p>
<pre>   print &quot;$date&quot;;     # calls $date-&gt;STRING, which in this case would
                      # print out a ctime formatted date string</pre>
<p>The call to <code>$object-</code>STRING&gt; would be a decision made by Perl, similar
to the way that <code>tie()</code> works. The object simply has to provide the
method; Perl does the rest.</p>
<p>This gives us several other really neat side effects. First, we can now
return a list of objects and have them act the same as a &quot;regular old
list&quot;:</p>
<pre>   (@objects) = Class-&gt;new;</pre>
<p>Since, in a stringifying context, each of these objects would call their
<code>STRING</code> methods:</p>
<pre>   print &quot;@objects&quot;;   # calls $objects[0]-&gt;STRING, $objects[1]-&gt;STRING,
                       # and so on for the whole array, thus making it
                       # look like a plain old list</pre>
<p>As such, we no longer have to distinguish between objects and &quot;true&quot;
scalars. Objects are automatically converted when appropriate.</p>
<a name='IMPLEMENTATION'></a><h1>IMPLEMENTATION</h1>
<p>All core objects should be modified to include a <code>STRING</code> function.
This function may just be a typeglob pointing to another function, or it
may be an actual separate function.</p>
<p>Hooks will have to be put in Perl's string context so that if something
is an object, then that object's <code>STRING</code> method is called
automatically if it exists.</p>
<a name='MIGRATION'></a><h1>MIGRATION</h1>
<p>None. This introduces new functionality.</p>
<a name='REFERENCES'></a><h1>REFERENCES</h1>
<p>RFC 159: True Polymorphic Objects</p>
<p>RFC 21: Replace wantarray with a generic want function</p>
<p>RFC 48: Replace localtime() and gmtime() with date() and utcdate()</p>
<p>Lots of people on perl6-language for great input, thanks!</p>
</div>
